home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
ccitt
/
1992
/
t
/
t101_a1.asc
< prev
next >
Wrap
Text File
|
1991-12-31
|
26KB
|
645 lines
ANNEX A
(To Recommendation T.101)
Interworking data syntax (IDS)
described in ASN.1 (Recommendation X.208)
Preamble
For Videotex interchange:
a) If two countries implement the same data syntax, then interworking can
use the same data syntax (DS I, or DS II, or DS III).
b) If two countries implement two different data syntaxes, then
interworking can use either:
i) the interworking data syntax (IDS) as defined herein, or
ii) any one of the three data syntaxes and convert directly between DS
I/DS II/DS III. The data syntaxes may be identified by the ESC 2/5
F mechanism described in S 4.4.2 of the main body of Recommendation
T.101.
If the IDS is used, then the Administration in which country the data base
is located will be responsible to convert into the IDS and the Administration in
which country the user terminal is located will be responsible to convert from
the IDS.
If the direct conversion method is used instead of using the IDS, the IDS
would serve as a technical guide in designing the conversion process.
The IDS is not intended to be used in terminal to host communications.
A.1 Videotex page
A Videotex page in the interworking data syntax (IDS) is a
sequence of presentation commands expressed in a manner independent
of any of the terminal data syntaxes. This formulation of the
presentation information which composes a Videotex page is intended
to aid interworking between basically different terminal data
syntaxes. It does this by isolating the unique and common elements
between each of the data syntaxes. The interworking data syntax is
not meant to be used as a terminal data syntax in its own right.
One encoding of the interworking data syntax is that defined in
Recommendation X.209. Other types of encoding are for further
study.
Videotex-Page ::= SEQUENCE OF Presentation-Commands
Presentation-Commands ::= SEQUENCE { State-Vector,
Function-&-Parameters }
A.2 State vector
A state victor is defined along with each presentation command
to establish the relationship of that presentation command to each
other presentation command. Although the information explicitly
contained in the state vector is also implicitly contained within
each presentation command, it would require the conversion
apparatus to fully understand each of the three terminal oriented
data syntaxes to uncover this information. Therefore a state vector
is included with each presentation command in which a global state
is affected or in which a boundary value is encountered, so that
the conversion process might operate on a general level.
State-Vector ::= CHOICE { [1] Vector-Definition
[2] Reset-State-Vector,
[3] NULL }
A.2.1 Vector definition
Vector-Definition ::= SEQUENCE {
Global-State-Affected-Indicator,
Terminal-Model-Precedence,
Boundary-Condition-Definition }
-- Only that information which changes between state vectors need
be communicated. If there is no change in a particular
component of the state vector, then that component need not be
communicated. This means that the state vector is not
communicated often and does not introduce significant
Fascicle VII.5 - Rec. T.101 PAGE13
overhead.
PAGE44 Fascicle VII.5 - Rec. T.101
A.2.1.1 Global state affected indicator
The global state affected indicator carries information
relating to the global states of the presentation data syntax.
Global state variables are variables representing those states of
the presentation data syntax which are established by presentation
commands and which carry on to affect the results of subsequent
presentation commands. By declaring the global state variables
explicitly, it is not necessary for the conversion process to
undarstand the interrelationship between presentation commands.
This means that the conversion process does not have to simulate a
terminal of the source data syntax in order to handle the
conversion of its elements.
The global state affected indicator does not carry information
about the value to which a global state has been set. That
information is carried within the `Function and Parameter` section
of the IDS. The indicator merely identifies which states have
changed. This is of great importance in situations where it is
necessary for the conversion process to sort the presentation
commands to account for differences in the terminal model used in
the source and destination of the interchange. If the order of
presentation commands is altered, the conversion process must
establish the appropriate global variables before each command in
the altered sequence. By referring to the global state affected
indicator, the conversion process can determine which global states
must be re-established. For example, if a sorting of presentation
commands is necessary to convert from a multi-plane to a single
plane terminal mode, and colour control commands have been used,
then the global state affected indicator will indicate that the
appropriate colour state must be established ahead of each portion
of the sorted data.
In some of the terminal data syntaxes attributes have global
effects while in other data syntaxes the effects are localized
according to the particular display primitive type. For example, in
Data Syntax III a colour command remains in effect for all
primitives, until the next colour command, whereas in Data Syntax
II there are various colour states which apply independently to
different primitives, such as LINE colour, FILLED AREA colour, etc.
The global state indicator carries a reference to a number of
independent `attribute state vectors` which define the attribute
context. For those data syntaxes which make use of only global
parameters, only one `attribute state vector` need be referenced.
For other data syntaxes which make use of multiple localized
attributes, several `attribute state vectors` may be referenced.
Global-State-Affected-Indicator ::= SEQUENCE {
attribute-state-vector-reference INTEGER,
attribute-affected-indicators SEQUENCE OF {
INTEGER {
current-text-position (1),
current-foreground-colour (2),
current-auxiliary-colour (3),
lining-state (4),
flash-blink-state (5),
basic-char-size-state (6),
conceal-state (7),
char-invert-box-state (8),
char-marking-state (9),
screen-protection-state (10),
display-control-state (11),
device-control-state (12),
cursor-control-state (13),
geometric-control-1-state (14),
Fascicle VII.5 - Rec. T.101 PAGE13
geometric-control-2-state (15),
wait-state (16),
general-text-state (17),
p-text-state (18),
geometric-text-state (19),
DRCS-definition-state (20),
macro-definition-state (21),
texture-pattern-state (22),
music-part-memory-state (23),
animation-configuration-state
(24),
workstation-configuration-state (25)
} } }
-- The Global State Affected Indicator consists of a set of
indicator flags which identify particular global states or in
some cases categories of global states which may be altered by
presentation and control commands. Some states, such as all
the forms of Flashing and Blink processes, are grouped
together for simplicity.
A.2.1.2 Terminal model
The terminal model differs significantly between the various
terminal data syntaxes. For the presentation of static images this
manifests itself in the manner by which presentation commands
overlay each other. A picture developed for a multi-plane terminal
model can be represented on a terminal using a single-plane
terminal model or a multi-plane terminal model with a different
order of precedence for the planes, by sorting the presentation
commands so that they build up an equivalent picture. The sorting
operation is necessary since otherwise the buildup order might
conflict with the precedence order in the new environment. The
terminal model precedence indicator is simply a numeric indicator
of the overlay precedence for presentation commands intended by the
source terminal data syntax. The conversion process is independent
of the terminal model or a particular data syntax and simply sorts
presentation commands based on this indicator. Note that certain
commands such as resets which have an effect in more than one plane
of a terminal model might have to be repeated in different parts of
the presentation sequence after the sort. The terminal model
precedence indicator consists of a sequence of numbers to indicate
the effect of a command across the terminal model.
Terminal-Model-Precedence ::= INTEGER
t
the information is communicated. For Data Syntax I, the order
is not fixed since certain `planes` of memory may be changed
in precedence by the ASSIGN FRAME command.
VV The value `0` has special meaning for the Terminal Model
Precedence Indicator. It indicates that the identified
information requires special interpretation. Such special
information includes partial reset commands which affect more
than one layer of the terminal model, as well as commands
having a time dependent effect, specifically WAIT, the BEL
character, and REVEAL.
A.2.1.3 Boundary conditions
Boundary condition variables represent the limits within which
the particular presentation command has been defined. Each
presentation command takes on its normal interpretation only within
a certain range of values. For example, the number of characters
which may be displayed on the screen varies between each of the
source terminal data syntaxes, and therefore the operation of
presenting a single character cannot be considered to be the same
in each terminal data syntax. To factor out the commonality, the
boundary condition of encountering the edge of the display area is
identified separately from the presentation of a character. This
aids conversion since it means that the boundary conditions
applying to each presentation command are given explicitly. The
PAGE44 Fascicle VII.5 - Rec. T.101
conversion process is therefore independent of the internal
boundary conditions within each of the source terminal data
syntaxes.
BoundaryVConditionVDefinition ::= SET { [1] ScreenVDimensions,
[2] ColourVMapVLimit,
[3] PresentationVSubVArea,
[4] CharVModeVConstraints,
[5] CoordinateVLimitVPolygon,
[6] CoordinateVLimitVSpline,
[7] PresentationVResolution,
[8] MacroVSegVMemoryVLimit,
[9] DRCSVMemoryVLimit,
[10] DirectVColoursVLimit }
Fascicle VII.5 - Rec. T.101 PAGE13
A.2.1.3.1 Screen dimensions
Screen-Dimensions ::= SEQUENCE { INTEGER, INTEGER }
-- Screen-Dimensions indicates the aspect ratio of the display
screen expressed in terms of a fraction of the Y and a
fraction of the X unit dimensions, where the INTEGER number
represents a binary fraction with an implied binary point
before the most significant bit. Note that a dimension of
(1,1) implies no geometric constraint. A character mode
service could use (1,1) to imply no constraint.
A.2.1.3.2 Colour map limit
Colour-Map-Limit ::= INTEGER
-- The colour map limit indicates the maximum number of colours
which may be stored in a single colour map, or the combined
total for multiple colour maps, and represents the maximum
number of colour states which may be encountered in a
particular presentation page. In the case where no colour map
is used, the integer specifies the number of fixed colours.
A.2.1.3.3 Presentation sub-area
Presentation-Sub-Area ::= SEQUENCE { Abs-Coord,
Rel-Coord, INTEGER, INTEGER }
-- The two coordinates give the boundary dimensions of a sub-area
of the display screen both in terms of the dimensions of the
sub-area and the number of characters per row and the number
of columns. The absolute coordinate specifies the origin of
the sub-area, the relative coordinate the size of the sub-area
and the INTEGER coordinates the limit on characters per row
and rows respectively.
A.2.1.3.4 Char mode constraints
Char-Mode-Constraints ::= SEQUENCE { INTEGER, INTEGER }
-- The two parameters give the limit to the number of characters
per row and the number of rows of text which may be presented
on the display screen; that is, the the boundaries at which
character (or word) wrap and scroll will occur.
A.2.1.3.5 Coordinate limit polygon
Coordinate-Limit-Polygon ::= INTEGER
-- The polygon coordinate limit specifies the maximum number of
coordinates which may be specified for a filled polygon.
A.2.1.3.6 Coordinate limit spline
Coordinate-Limit-Spline ::= INTEGER
-- The spline coordinate limit specifies the maximum number of
coordinates which may be specified.
A.2.1.3.7 Presentation resolution
Presentation-Resolution ::= SEQUENCE { INTEGER, INTEGER }
-- The presentation resolution specifies the nominal resolution
of the display screen which was used by the information
source.
A.2.1.3.8 Macro seg memory limit
Macro-Seg-Memory-Limit ::= INTEGER
o
of memory which is available for the storage of Macros or
Segments. The INTEGER parameter represents available memory
expressed in bytes.
A.2.1.3.9 DRCS memory limit
DRCSVMemoryVLimit ::= INTEGER
VV The DRCS memory limit specifies the upper bound on the amount
of memory which is available for the storage of DRCS. The
INTEGER parameter represents available memory expressed in
bytes.
A.2.1.4 Data syntax identifier (SID)
SID ::= IMPLICIT INTEGER { dataVsyntaxV I (1),
dataVsyntaxV II (2),
dataVsyntaxVIII (3) }
VV SID is an identifier which is referenced in a number of
primitive commands and which identifies the source data syntax
of the command.
PAGE44 Fascicle VII.5 - Rec. T.101
A.2.2 Reset state vector
ResetVStateVVector ::= SEQUENCE { SID, VectorVDefinition }
VV The Reset State Vector command is used to establish the
initial state for the Interworking Data Syntax. The default
state may be selected from the table corresponding to the
source terminal data syntax (or profile) given in Appendix II.
Alternate parameters may be specified by use of explicit state
vector and function and parameter definitions.
A.2.3 NULL
NULL implies that the state vector is unchanged from the
previous presentation command.
A.3 Functions and parameters
The functions and parameters which make up the presentation
commands are grouped into categories which depend upon their
commonality between the various terminal data syntaxes. Those
functions which are compatible, such as the basic repertoire of
alphanumeric characters defined in Recommendation T.51, define
separate groups. Those functions which are unique, such as certain
specific special characters, also establish separate groups so that
they may be converted or otherwise handled in a special manner.
Functions such as DRCS and graphics drawing commands, which differ
in fundamental ways between the various terminal data syntaxes, are
organized so that those underlying capabilities which are common
may be exploited in the necessary conversion process.
FunctionsV&VParameters ::= CHOICE { [0] AlphaVCharVString,
[1] SpecialVCharVString,
[2] KanaVCharVString,
[3] KanjiVCharVString,
[4] BlockVMosaicVString,
[5] SmoothVMosaicVString,
[6] SpecialVMosaicVString,
[7] FormatVEffectorVC0VChars,
[8] SpecialVFormatVC0VCharacters,
[9] GeneralVControlVCharacters,
[10] GeometricVString,
[11] Animation-Control-String,
[12] Segment-Control-String,
[13] Colour-Control-String,
[14] Text-Control-String,
[15] Photo-Graphic-String-Syntetic-Image,
[16] Photo-Graphic-String-Natural-Image,
[17] MACRO-String,
[18] DRCS-String,
[19] Fill Pattern-Control-String,
[20] Music-String,
[21] Tele-Software-String,
[22] Audio-Data-String,
[23] Greek-Char-String }
The first six categories of functions and the last one are
various text or mosaic characters. None of the terminal data
syntaxes defined in Recommendation T.101 encompasses all of these
characters. There are different unique characters in each of the
terminal data syntaxes. However, a large portion of the repertoire
is common between the different terminal data syntaxes, although
the characters may be coded differently. Since coding is irrelevant
here, and the use of particular tables could in fact cause serious
confusion, characters extracted from the different character
repertoires will be distinguished by the identifier name codes for
each character as defined in Recommendation T.51. Since all of the
terminal-oriented data syntaxes in Recommendation T.101 do not
explicitly make use of these name codes in the body of the
Fascicle VII.5 - Rec. T.101 PAGE13
Recommendation, the entire character repertoire, together with the
name codes for each character are included here as an appendix.
PAGE44 Fascicle VII.5 - Rec. T.101
A.3.0 Alpha char string
Alpha-Char-String ::= GRAPHICSTRING
-- Characters (LA01 to LZ30, ND01 to ND09 and ND10, SC01 to SC05,
SP01 to SP22, SA01 to SA07, NS01 to NS03, NF01 to NF21, SM01
to SM44 and SM47 to SM49, and SD11 to SD43) taken from
Repertoire 1 which are the characters from the primary and
supplementary character sets of Recommendation T.51 together
with the SPACE character (SP01) and DELETE character (SM34).
-- The coding of characters within an Alpha Character String will
be taken from the IRV primary character code table (ISO
Registration Number 2 under ISO 2375) and the secondary code
table for use with IRV from ISO 6937/2 (ISO Registration
Number 90).
-- Note - The coding for the character $ "Dollar Sign" (SC02)
will be taken from the supplementary character set.
-- Note - The coding for the character ## "number sign" (SM01)
will be taken from the primary character set.
-- Note - The coding for the character "general currency sign"
(SC01) will be taken from the primary character set.
A.3.1 Special char string
Special-Char-String ::= INTEGER {
non-spacing-vector-overbar (1),
non-spacing-slant (2),
left-vertical-bar-jointive
(3),
right-vertical-bar-jointive
(4) }
-- Non-Spacing-Vector-Overbar is a character (SM50) from
Repertoire 2.
-- Non-Spacing-Slant is a character (SM51) from Repertoire 2.
-- Left-Vertical-Bar-Jointive is a character (SM45) from
Repertoire 2.
-- Right-Vertical-Bar-Jointive is a character (SM46) from
Repertoire 2.
A.3.2 Kana char string
Kana-Char-String ::= GRAPHICSTRING
-- Characters (JA01 to JA63) taken from Repertoire 3.
-- The coding of characters within a Kana Character String will
be taken from the Kana character code table (ISO Registration
Number 56 under ISO 2375).
A.3.3 Kanji char string
Kanji-Char-String ::= GRAPHICSTRING
-- Characters (JK01 to JK2980, HK01 to HK83, and JS01 to JS366)
from Repertoire 4.
-- The coding of characters within a Kanji Character String will
be taken from the two byte Kanji character code table (ISO
Registration Number 87 under ISO 2375).
Fascicle VII.5 - Rec. T.101 PAGE13
